home *** CD-ROM | disk | FTP | other *** search
/ Amiga Aktuell / Amiga Aktuell.iso / amiga-aktuell / net tools / fido net / ftsc-all-91 / fsc-0007.z02 / FSC-0007.002
Text File  |  1990-04-17  |  14KB  |  311 lines
  1. Document: FSC-0007
  2. Version:  002
  3. Date:     17-Apr-90
  4.  
  5.  
  6.  
  7.  
  8.  
  9.                FidoNet(r) RFC822-Style Message Format
  10.     (Informal Proposed Message Format Specification - Draft, revised)
  11.              Robert Heller @ 1:321/153.0
  12.                           April 17, 1990
  13.  
  14.  
  15.  
  16.  
  17.  
  18. Status of this document:
  19.  
  20.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  21.      and requests discussion and suggestions for improvements.
  22.      Distribution of this document is unlimited.
  23.  
  24.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  25.      Software.
  26.  
  27.  
  28.  
  29.  
  30.  
  31. 1. Purpose.
  32. ===========
  33.  
  34. The purpose of this document is to outline my ideas concerning
  35. FidoNet (r) message format, both as stored on disk as message
  36. files handled by BBS (or other "conferencing" programs) and as
  37. these messages exist packed into "bundles" or "packets" as
  38. transmitted from machine to machine.  I think using a uniform
  39. format for normal message storage will make things easier, at
  40. least in terms of "standardized" message bundling and transmiting
  41. software is concerned.  If done right it also makes things easier
  42. for BBS and conferencing software writers too.
  43.  
  44. This specification is only a first draft proposal.  Just
  45. something to put on the table for discussion. Feel free to
  46. comment on it. I am open to suggestions.
  47.  
  48. 2. Preliminary Definations.
  49. ===========================
  50.  
  51. I will be using BNF notation to describe the format of data
  52. fields.  This is a fairly standard notation and should be familar
  53. to anyone who has taken a compiler design course.  To make things
  54. a little briefer, I will be using some pre-defined
  55. psuedo-terminal symbols.  These symbols are defined as:
  56.  
  57.    o The symbol ALPHA referes to any ASCII alphabetic character,
  58.      including the uppercase letters ('A' thru 'Z', 41H thru
  59.      5AH), the lowercase letters ('a' thru 'z', 61H thru 7AH) and
  60.      these characters: '#' (23H), '$' (24H), '&' (26H), '*'
  61.      (2AH), '+' (2BH), '-' (2DH), '=' (3DH), '^' (5EH), and '_'
  62.      (5FH).
  63.  
  64.    o The symbol DIGIT refers to any of the ASCII characters '0'
  65.      thru '9' (30H thru 39H).
  66.  
  67. |  o The symbol NEWLINE refers to the single ASCII character LF (0AH),
  68. |    when the message is in transit, and refers to the local O/S's
  69. |    newline convention for text files (i.e. LF under UNIX, CRLF under
  70. |    MS-DOS and CP/M, CR under OS-9, etc.), or whatever is convient for
  71. |    the BBS software.
  72.  
  73.    o The symbol WHITESPACE refers to one or more ASCII space
  74.      (20H) or tab (09H) characters. 
  75.  
  76.    o The symbol OPTWHITESPACE referes to zero or more ASCII space
  77.      (20H) or tab (09H) characters.
  78.  
  79.    o The symbol TEXT referes to zero or more printable ASCII
  80.      characters not including a NEWLINE sequence.
  81.  
  82.    o The symbol NULL referes to the null string (no characters at
  83.      all).
  84.  
  85. Oh, one other thing:  message files contain only printable ASCII
  86. characters and NEWLINE sequences (packed messages will have
  87. non-printable bytes).  Also, I'll number the definations.  I am
  88. also only using six BNF operator characters: a vertical bar (|)
  89. for alteration, braces ({}) for comments, single quotes (') for
  90. character and string literals and parens (()) for expression
  91. grouping. 
  92.  
  93.  
  94. 3. Definations 1: Stored Message.
  95. =================================
  96.  
  97.  
  98. Changed or added definations are indicated by an '*' after the def number.
  99.  
  100. The goal symbol is "<message>".
  101.  
  102.    { A message consists of a header followed followed by a
  103.      NEWLINE followed by a message body. }
  104. <message>::=<header> NEWLINE <message-body>        {Def 1.1}
  105.    { A message body is just unbounded text. }
  106. <message-body>::=NULL | (TEXT NEWLINE <message-body>)   {Def 1.2}
  107.    { A header is more complicated:  There are a series of
  108.      header line types. }
  109. <header>::= NULL | (<header-line> NEWLINE <header>)    {Def 1.3} *
  110.    { This syntax defines the posiblity of a null header - 
  111.      this needs to be checked for by sematic routines,
  112.      since it makes no sense. }
  113. <header-line>::=<to>|<from>|<date>|<attributes>|
  114.         <cost>|<subject>|<via>|<origin>|
  115.         <area>|<seen-by>|<path>|<message-id>|
  116.         <processed-by>|<other-header-line>      {Def 1.4} *
  117.    { Now for the header line formats themselves.
  118.      Some notes:  certain header lines are required (<to>,
  119.      <from>, and <date>), and some can only occur once (<to>,
  120.      <from>, <date>, and <subject>). Except for these
  121.      restrictions, most header lines can either be omited or can
  122.      occur more than once. }
  123. <to>::='To: ' <address>                    {Def 1.5}
  124. <from>::='From: ' <address>                {Def 1.6}
  125. <address>::=<user> OPTWHITESPACE '@' OPTWHITESPACE 
  126.         <nodeid>                    {Def 1.7}
  127. <user>::= ALPHA <user1>                    {Def 1.8}
  128. <user1>::= (ALPHA | DIGIT | WHITESPACE | NULL) <user1>    {Def 1.9}
  129.     { Note: this is the full blown FidoNet node address -
  130.       includes optional zone and point numbers.
  131.       It does not include the "domain". I am not sure
  132.       about this - I think more discussion on the whole
  133.       idea of "domains" and "zones" is needed.  My feeling
  134.       is we should look into a symbolic addressing system,
  135.       simular to what the InterNet uses. }
  136. <nodeid>::= ((<digits> ':') | NULL) {zone}
  137.         <digits> '/' <digits>   {basic net/node}
  138.         (('.' <digits>) | NULL) {point}        {Def 1.10}
  139. <digits>::= DIGIT | (DIGIT <digits>)            {Def 1.11}
  140. <date>::='Date: ' <date-string>                {Def 1.12}
  141.     { Here it is: my idea for a *standard* date string }
  142.   { day-of-week month date, year hour:minute AM/PM time-zone }
  143.   { Although not specified, hours and minutes are zero padded to
  144.     two digits.  The date and year are not padded at all.}
  145. <date-string>::= <day> ' ' <month> ' ' <digits> ', ' 
  146.          <digits> ' ' <digits> ':' <digits> 
  147.          <am-pm> ((' ' <time-zone> | NULL)    {Def 1.13}
  148. <day>::= 'Mon" | 'Tue' | 'Wed' | 'Thu' | 'Fri' | 
  149.      'Sat' | 'Sun'                    {Def 1.14}
  150. <month>::= 'Jan' | 'Feb' | 'Mar' | 'Apr' | 'May' | 
  151.        'Jun' | 'Jul' | 'Aug' | 'Sep' | 'Oct' |
  152.        'Nov' | 'Dec'                {Def 1.15}
  153.     { If the AM/PM indicator is missing (null), the hours
  154.       field is assumed to in 24-hour format (i.e. 00 to 23) }
  155. <am-pm>::= 'AM' | 'PM' | NULL                {Def 1.16}
  156.     { This field is optional.  It makes sense given that
  157.       FidoNet <tm> is international. }
  158. <time-zone>::= ALPHA | (ALPHA <time-zone>)        {Def 1.17}
  159. <subject>::=('Subject: ' | 'Subject (Private): ') TEXT    {Def 1.18}
  160. <cost>::='Cost: ' <money-sign> <digits>
  161.      (('.' <digits>) | NULL)            {Def 1.19}
  162.     { This is tricky, given the internationalness
  163.           of FidoNet(r).  I guess it isn't critical. }
  164. <money-sign>::= '$' | '#' | NULL            {Def 1.20}
  165. <via>::= 'Via: ' <nodeid> ', ' <date-string> <program>    {Def 1.21}
  166. <program>::= NULL | (' ' TEXT)                {Def 1.22}
  167. <processed-by>::= 'Processed-by: ' TEXT         {Def 1.22.1} *
  168.     { This replaces the 'tear' line. }
  169. <origin>::= 'Origin: ' TEXT '(' <nodeid> ')'        {Def 1.23} *
  170. <area>::= 'Area: ' <areaname>                {Def 1.24}
  171.     { I'm leaving the question of all caps for the
  172.       area name open:  other than ease of comparision,
  173.       is it neccessary to be all caps? }
  174. <areaname>::= ALPHA | (ALPHA <areaname>)        {Def 1.25}
  175. <seen-by>::= 'Seen-By: ' <node-list>            {Def 1.26} *
  176. <node-list>::= <nodelist-nodeid> | 
  177.           (<nodelist-nodeid> <node-list>)    {Def 1.27} *
  178. <nodelist-nodeid> ::= ((<digits> ':') | NULL)
  179.           ((<digits> '/') | NULL) 
  180.           (<digits> | NULL)
  181.           (('.' <digits>) | NULL)        {Def 1.28} *
  182.     { This is also open-ended.  Should there be a
  183.       standard format for this?
  184.       The syntax here is somewhat ambigious - it 
  185.       allows for certain bogus forms.  It needs sematic
  186.       routines to handle these forms (raise an error 
  187.       or whatever).  Writing the grammer to avoid these
  188.       problems would add complexity not needed at this
  189.       level. }
  190. <path>::= 'Path: ' <node-list>                {Def 1.28.1} *
  191. <message-id>::= 'Message-id: ' <nodeid> ' ' <serialnum>    {Def 1.29} *
  192.     { This is the syntax proposed by Jim Nutt }
  193. <serialnum>::= {8 hex digits}                {Def 1.29.1} *
  194.     { I've left out a proper grammer rule or token 
  195.       for a hexidecimal number. }
  196. <attributes>::= 'Attributes: ' <attrlist>        {Def 1.30}
  197. <attrlist>::=<attribute> | (<attribute> ', ' <attrlist>){Def 1.31}
  198.     { This is probably not complete, but...}
  199. <attribute>::='Kill Sent' | 'File Attached' | 'File Request' |
  200.           'Sent' | 'Crash' | 'Audit'        {Def 1.32}
  201.     { Maybe we should forget about an 'Attributes: ' 
  202.       header tag and instead have a collection of
  203.       additional header tags to handle each posible
  204.       attibute - i.e. 'File-Attached: <filename>',
  205.       'File-Request: <filename> <update-info>',
  206.       'Sent: <date-sent>', etc. header lines. }
  207. <other-header-line>::=<tagname> ': ' (TEXT | NULL)    {Def 1.33}
  208.     { This is the expandsion hook. }
  209. <tagname>::= ALPHA <tagname1>                {Def 1.34}
  210. <tagname1>::=NULL | ((ALPHA | WHITESPACE | DIGIT |
  211.          <pun> <tagname1>)                {Def 1.35}
  212.     { This is also open-ended.  Restriction: colon (:)
  213.       cannot be allowed! }
  214. <pun>::='(' | ')' | '.' | ',' | ';'            {Def 1.36}
  215.  
  216. 4. Packed Message Format.
  217. =========================
  218.  
  219. A packed message is simply a regular message with some binary
  220. header (i.e. an "envelope") info and a NUL (00H) byte after the message
  221. text: 
  222.  
  223.        Offset
  224.       dec hex
  225.               .-----------------------------------------------.
  226.         0   0 |    0     |     3      |    0      |    0      |
  227.               +-----------------------+-----------------------+
  228.         2   2 | origZone (low order)  | origZone (high order) |
  229.               +-----------------------+-----------------------+
  230.         4   4 | origNet  (low order)  | origNet  (high order) |
  231.               +-----------------------+-----------------------+
  232.         6   8 | origNode (low order)  | origNode (high order) |
  233.               +-----------------------+-----------------------+
  234.         8   8 | origPoint (low order) | origPoint (high order)|
  235.               +-----------------------+-----------------------+
  236.        10   A | destZone (low order)  | destZone (high order) |
  237.               +-----------------------+-----------------------+
  238.        12   C | destNet  (low order)  | destNet  (high order) |
  239.               +-----------------------+-----------------------+
  240.        14   E | destNode (low order)  | destNode (high order) |
  241.               +-----------------------+-----------------------+
  242.        16  10 | destPoint (low order) | destPoint (high order)|
  243.               +-----------------------+-----------------------+
  244.        18  12 | Attribute (low order) | Attribute (high order)|
  245.               +-----------------------+-----------------------+
  246.        20  14 |      message text (includes ASCII header)     |
  247.               ~                    unbounded                  ~
  248.               |                 null terminated               |
  249.               `-----------------------------------------------'
  250.  
  251. Some notes:  I've included both the Zone and Point addresses in
  252. the packed message headers.  This does not really affect things
  253. like routing and point mapping.  The packets themselves have
  254. addressing info in their headers (as described in FSC001).  The
  255. addressing in the packet header - this addressing is used by the
  256. transmitting programs.  The internal addressing info is processed
  257. by re-packing programs - that is programs which peel routed
  258. messages (messages that are "just passing through") and re-packet
  259. them for later re-transmitsion to another node during a future
  260. mail event.  Messages destined for the current node (one whose
  261. address exactly matches all four destination address words), get
  262. extracted from the packet and stored in the message base.  Note
  263. that only the ASCII message text is stored.  The binary header is
  264. discarded at this point. 
  265.  
  266. 5. Conclusions.
  267. ===============
  268.  
  269. It is my idea that FidoNet(r) is going to sooner or later going
  270. need some of the extendablity provided by this sort of message
  271. format. If fact it allready needs some of these fields, and has
  272. been "faking it" for some time now: things like EchoMail (
  273. "Area: ", "Origin: ", "Seen-By: ", and "Path: " header lines), points
  274. and zones (extra addressing hacks), uucp gatewaying (more extra
  275. addressing hacks), routing ("Via: " header lines).  Going to a
  276. RFC822-style message format also helps to increase the varity of
  277. BBS and conferencing software - this will help improve the "state
  278. of the art" in this regard.  Also, using a RFC822-style message
  279. format allows indefinite extensablity - as new ideas regarding
  280. messages and conferencing develope, the message format can be
  281. easily extended to handle these new ideas with ease.
  282.  
  283. 6. Contact Info.
  284. ================
  285.  
  286. Comments, suggestions, gripes, etc. can be sent to me at any of
  287. these addresses: 
  288.  
  289.     ARPANet:    Heller@CS.UMass.Edu
  290.     BITNET:        Heller@UMass.BitNet
  291.     Genie:        RHELLER
  292.         BIX:            lockshill.bbs
  293.     CompuServe:    71450,3432
  294.     FidoNet        Robert Heller @ 1:321/153.0
  295.     USMail:        HC82 Box 29 LH1, Locks Hill Road, Wendell, MA 01379
  296.     Voice Phone:    Home: 617-544-6933, Work: 413-545-0528
  297.     Data Phone:    617-544-8337 at 300, 1200, or 2400 BAUD 24hours,
  298.                         except during FidoNet(r) mail periods.
  299.  
  300. 7. More Information.
  301. ====================
  302.  
  303. I have written a set of EchoMail processing using a message format
  304. described in this document.  The code is in C and is freely available
  305. for evalation.  If you would like a copy, let me know and I will get a
  306. copy to you.  I developed the code under OS-9/68000, but the code should
  307. easily port to other platforms.
  308.  
  309.  
  311.